Any software that is previously installed (“pre-installed software”) and currently executing in systems of computers in an enterprise or organization may need to be changed, for example to keep up with new requirements, latest technologies, and fix defects (“bugs”). A vendor of the pre-installed software may release additional software (“patch”) to fix bugs in the pre-installed software. Patches are typically released in a binary form, and used to overwrite portions of pre-installed software also in binary form. Note that if the pre-installed software is in another form, e.g. byte codes, then the patch is also released in the same form, e.g. also byte codes. For example, Oracle® Corporation releases a bundle of patches (“Critical Patch Update” or CPU) on a quarterly basis to provide security fixes for ORACLE® products.
Specifically, ORACLE® CPUs are released every quarter on a pre-announced date at a predetermined website. Each CPU contains patches in patch files, and also contains files of supporting documentation (“metadata”), including a documentation roadmap. The documentation roadmap helps a human decide on appropriate patches for specific software in the systems of computers (“enterprise systems”). The metadata also indicates actions to be performed with the patch files during deployment, e.g. actions to replace files of pre-installed software with newer version of the software in files released as patches. Patches in a CPU can be either cumulative (include fixes in all earlier patches) or incremental (e.g. one-off patches).
The task of upgrading and/or patching of pre-installed software is normally handled by a human skilled in Information Technology (IT). For example, steps to be performed by IT personnel to keep the Oracle® Database software up-to-date with latest product fixes available from Oracle Corporation is described in Chapter 12 entitled “Managing Oracle Database Software” in the book Oracle® Database 2 Day DBA 11 g Release 1 (11.1), Part No. B28301-03, which is incorporated by reference herein in its entirety. An IT professional typically performs such a task on enterprise systems by first testing patch files on a test deployment (FIG. 1A) before applying them to a production system (FIG. 1B). For effective testing, the test environment is set up to resemble the production environment as closely as possible. Vendors of software products may provide software tools to assist IT professionals in selecting one or more patch files to be deployed, and thereafter automatically deploy the selected patch files to one or more computers in the enterprise systems that contain the software to be patched.
A software utility called “OPatch” is available from Oracle Corporation, Redwood Shores, Calif. Prior to installing a patch file, OPatch can be used to resolve patch conflicts, and do a version check. A patch conflict can arise, for example, if a previously applied patch touches certain files that are also touched by a new patch and the new patch is not a superset of the previously applied patch. OPatch checks for such situations and raises an error when it detects a conflict.
Another software utility called “Oracle Universal Installer” is normally used to install ORACLE products (i.e. not patches, but entire products). Oracle Universal Installer (OUI) maintains an inventory which can be used by OPatch to detect conflicts by issuing the following command “opatch apply-silent-no_bug_superset-report”. The -report option detects any conflicts without applying the patch.
For more information on the above-described two tools, namely OPatch and OUI, see the following document which is incorporated by reference herein in its entirety: Chapter 7 of Oracle® Universal Installer and OPatch User's Guide, 11 g Release 1 (11.1) for Windows and UNIX, Part No. B31207-03, January 2008, entitled “Patching Oracle Software with OPatch.”
Another software tool called ORACLE® Enterprise Manager 10.2.0.5 is also available from Oracle Corporation, Redwood Shores, Calif. The Enterprise Manager (EM) provides a central management console to manage computers in a system containing software from ORACLE Corporation. Using this management console, an IT professional can identify patches applicable to their enterprise system, schedule CPU patching across multiple computers in the enterprise, and apply patches to multiple ORACLE_HOMEs at the same time (scalable patching model).
If any issues arise during patch deployment, the IT professional to take corrective action can use the EM. The EM can also be used to automate parts of the CPU implementation tasks by developing the necessary extensions to existing change management tools or systems. The following article is incorporated by reference herein in its entirety as background, entitled “Saving Time and Labor On ORACLE Patching With Enterprise Manager Provisioning Pack—a case study with Oracle Internal IT” dated January 2008, by Pankaj Chandiramani and Hariprasanna Srinivasan.
Moreover, please see the following documents which are also incorporated by reference herein in their entirety as background: (1) Chapter 10 of Oracle® Enterprise Manager Advanced Configuration, 10g Release 4 (10.2.0.4.0), E10954-01, October 2007, entitled “Using Enterprise Manager For Grid Automation With Deployment Procedures.” (2) Chapter 6 of Oracle® Enterprise Manager, Concepts, 10 g Release 1 (10.1), Part No. B12016-0, December 2003 entitled “Managing Deployments.”
Furthermore, also incorporated by reference herein in their entirety are the following: (1) US Patent Publication 20070288903 by Manglik et al. entitled “AUTOMATED TREATMENT OF SYSTEM AND APPLICATION VALIDATION FAILURES”; (2) US Patent Publication 20080098099 by Khasnis et al. entitled “FACILITATING DEPLOYMENT OF CUSTOMIZATIONS OF ENTERPRISE APPLICATIONS”; (3) US Patent Publication 20060225072 by Lari et al, entitled “Packaging multiple groups of read-only files of an application's components into multiple shared libraries”; and (4) US Patent Publication 20080178173 by Sriram et al, entitled “Enhanced Flexibility In Deployment of Patches to Fix Errors In Pre-Installed Software.”
Software tools of the type described above assist an IT professional in deploying to one or more target computers, a patch that the IT professional has personally selected e.g. based on the IT professional's knowledge of the target environment in their enterprise system. The target environment includes vendor-specific types of hardware (e.g. IBM-PC or Sun Workstation), as well as vendor-specific software, such as the type of operating system (e.g. Unix or Windows), and/or application software (e.g. PeopleSoft or Siebel).
Inventors of the current patent application note that due to the diverse nature of hardware and software in the computers of an enterprise system, deployment of patches can cause unforeseen problems. For example, the IT professional may not think of some critical functionality of a computer that is found to be adversely affected after applying a patch, resulting in the computer becoming unavailable until the original configuration is restored.
Inventors of the current patent application further note that restoring an adversely affected computer back to its original configuration is difficult and time consuming. Even if there is no critical failure, a newly-applied patch in one software tier (e.g. application software) may conflict with a previously-applied patch in another software tier (e.g. middleware software), requiring roll-back (i.e. removal) of the previously-applied patch. Accordingly, the inventors of the current patent application believe there is a need for a new tool of the type described below, to improve the process of deployment of a patch.